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Xanadu Light: Starting Model 


BASIC MODEL 
The basic model of a document in Xanadu Light is of owned bytes 
(text, pictures, video, audio, etc.) and connections. 


In this starting model, material is sequential. There is no 
hyperstructure, there are no overlays. Additions will be made for 
these at a later time. 


CONNECTIONS 
Any document may connect to any other on the network. The 
document making the connection we call the choosing document. 


Node A 


— Node B 


document B 


The connections are of two types: transclusions (virtual inclusions 
from other documents-- "bring this material in here") and links of 
arbitrary type. 
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BASIC 


XANADU Pm 


transclusion: 
DOCUMENT MODEL BRING THIS IN FRO 






SEWHERE 






CONNECTIONS 


Document includes outbound 


connections chosen by author, allowing _ link (OF ARBITRAG?E) 
virtual inclusion (transclusion) of 


material from any other document, and 
linkage to any other document. 


For implementation, however, the document must have local 
notification of incoming connections. These are maintained with 
the document in the same node. 


Remote end of link must be 
stored with target document. 


Node A 








— Node B 
document B 
Inbound 
om ac 
. (“harpoon”), 
Outbound link, stored stored with 
with document target document 


This means that local to the document is a registry of inbound 
connections not under control of the original publisher. 
Diagrammatically: 
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COMPLETED 
BASIC XANADU 
transclusion: 


f* Inbound onnections made from other 
documents are symmetrical to outbound _link (OF ARBITRANIP 
connections from this one. However, 
they are not controlled by the present 
publisher. 


THE BASIC TABLES 
These connections are visible in public tables and may be seen by 


anybody without logging into the document. Storage costs are 
borne by the publishers. 


\. 








Search costs are borne by the users. 


BASIC TABLE 1: THE DOCUMENT TABLE 
The document table is owned, maintained and controlled by the 


publisher. 


AS REPRESENTED IN PUBLIC DATABASE TABLES-- 
BASIC DOCUMENT ITSELF (storage paid by publisher) 


PIECES OF DOCUMENT (bytes) 


type owner royalty where stored | link type 












destination 
bytes 
(anywhere) 


unde 
source bytes 
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The document table lists its parts, their ownership and cost. This 
implicitly states the transclusions of the system: the contents of the 
document are simply listed as its byte pieces, regardless of where 
they are or who owns them. 


The document table also lists outbound links. Transclusions need 
not be listed separately, as they are implicit in the list of pieces. 


BASIC TABLE 2: THE INBOUND TABLE 
The table of inbound links is stored with the document to which 
they point. Each entry (or "harpoon") is generated implicitly by 
another document's publishing an outbound link or transclusion to 
this document. 


AS REPRESENTED IN PUBLIC DATABASE TABLES-- 
DOCUMENT'S INBOUND CONNECTIONS or Harpoons 
(stored with the document; storage paid by OTHER publishers) 


INBOUND LINKS AND TRANSCLUSIONS 


link type or | Owner choosing bytes 
transclusion addresses connected to 
(anywhere) here 




















The publisher of this document does not pay for this table, since it 
is not under this publisher's control. The payment is by the several 
contributing publishers who created the outbound links that 
became these inbound connectors. 


BARNACLES 
For immediate delivery of quoted material, a publisher may choose 
to store a portion of the document being quoted with the new | 
document. This is permitted within the system. The publisher 
pays for the additional accessibility of the other document. It still 
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remains the property of the original publisher, and remands royalty 
to that original publisher. 


UNFURLMENT AND HEADER INFORMATION 
Delivery of bytes from different formats will be more or less 
convenient; unpacking or processing these bytes for addressability 
we call “unfurlment." 


Header information normally stored at the beginning of the file, 
and necessary to used part of it, must be sent along in parallel with 
the bytes. This is part of the Receipt Token delivered with the 
bytes. 


Additional costs associated with unfurlment and other file 
complexities are borne by the purchaser. 


